home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001358_daemon _Fri Jun 18 17:01:45 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  8KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA02375; Fri, 18 Jun 93 17:01:47 MET DST
  3. Return-Path: <dsr@hplb.hpl.hp.com>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA02371; Fri, 18 Jun 93 17:01:45 MET DST
  6. Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA05564; Fri, 18 Jun 1993 17:23:58 +0200
  8. Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
  9.     id AA29478 (5.65b/CWI-2.225); Fri, 18 Jun 1993 17:23:50 +0200
  10. Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 18 Jun 93 16:15:44 +0100
  11. Received: by manuel.hpl.hp.com
  12.     (16.6/15.6+ISC) id AA29719; Fri, 18 Jun 93 16:21:55 +0100
  13. From: Dave_Raggett <dsr@hplb.hpl.hp.com>
  14. Message-Id: <9306181521.AA29719@manuel.hpl.hp.com>
  15. Subject: Re: HTML+ Forms
  16. To: TONYJ@scs.slac.stanford.edu
  17. Date: Fri, 18 Jun 93 16:21:52 BST
  18. Cc: www-talk@nxoc01.cern.ch
  19. Mailer: Elm [revision: 66.36.1.1]
  20.  
  21. Hi Tony,
  22.  
  23. Sorry for the delay in getting back to you, I am rather snowed under
  24. these days.
  25.  
  26. > Hi Dave, do I take it from this comment that some examples exist of the 
  27. > use of <INPUT> and other form stuff? If so can I access them somewhere? I 
  28. > have a preliminary implementation of Forms for MidasWWW and would like 
  29. > some examples to try them out on.
  30.  
  31. Can you tell more about your implementation of Forms for MidasWWW?
  32.  
  33. I enclose the current HTML+ definitions for forms at the end of this
  34. message. The new FORM tag allows several forms to be included in
  35. the same document. This tag also defines what to do when the user
  36. presses the "commit" key (normally the Return key), e.g. to send the
  37. form's contents as a query to a server or to send it to a designated
  38. person as an email message. The new MH tag allows you to define
  39. arbitrary email header fields at the start of each message.
  40.  
  41. We still need to pin down how form contents can be passed to
  42. servers as queries etc. and I would be very grateful for some
  43. help in this regard. Some ideas for doing this with URLs are given
  44. later on.
  45.  
  46. Now for an example which supposes that a server has been set up to help
  47. sales staff configure quotes for computer workstations. It is based on
  48. an expert system I worked on a couple of years ago.
  49.  
  50.     <FORM action="http://ukrc.hp.com:8002/s720">
  51.         <H1>HP 9000 Series 720 Workstation</H1>
  52.  
  53.         <UL>
  54.             <LI> 50 MHz PA-RISC CPU
  55.             <LI> Wide range of graphics options
  56.             <LI> 16 to 128 Mb ECC RAM and 2 optional disks
  57.         </UL>
  58.  
  59.         <INPUT id="f1" type="INT" width="2" value="1"> Quantity </INPUT>
  60.  
  61.         <SELECT id="f2" compact> Graphics
  62.             <ITEM id="i1" selected> Mono GRX
  63.             <ITEM id="i2"> Color CRX
  64.             <ITEM id="i3"> 2D Color VRX
  65.         </SELECT>
  66.  
  67.         <SELECT id="f3" compact> Internal hard disks
  68.             <ITEM id="i4"> 1 x 420 Mb
  69.             <ITEM id="i5" selected error> 2 x 420 Mb
  70.         </SELECT>
  71.     
  72.         <INPUT id="f4" type="bool" value="true" error> 3.5 inch floppy drive
  73.  
  74.         <P>
  75.         *** You are only allowed two internal drives! ***
  76.     </FORM>
  77.  
  78. The form starts with a header and a list of features for the workstation.
  79. A quantity field follows which allows users to type a two digit integer.
  80. It is initialised to the value "1".
  81.  
  82. Next there is a selection menu. Users have to choose one of a range of
  83. graphics options. The initial value is the first item as indicated by
  84. the selected attribute. The compact attribute tells the browser to render
  85. the menu in a compact style, e.g. as a button with a drop down menu. For
  86. menus supporting multiple selections, you would need to show the current
  87. selections as a (truncated) list next to the dropdown button. The normal
  88. (uncompact) style would be a permanently visible list, perhaps with some
  89. kind of button to the left of each item, but visually distinct from
  90. bulleted lists defined with the UL tag.
  91.  
  92. Fields can be marked as being in error or greyed out (disabled). The latter
  93. case means the field cannot be altered - perhaps because its value is
  94. constrained by the values of other fields.
  95.  
  96. The next field is also a selection menu. In this case the selected item
  97. is marked as being in error and needing to be changed. The browser could
  98. indicate this by a red splash next to the menu item.
  99.  
  100. The last field is a boolean checkbox, currently checked. It too is marked
  101. as being in error and needing to be changed. The static text message which
  102. follows indicates the nature of the problem.
  103.  
  104. Menus and checkboxes can be altered by clicking the mouse. Other kinds of
  105. input fields require the user to set the input focus to that field, e.g.
  106. by clicking with the mouse or using the tab/shift tab keys. Input fields
  107. needing keyboard input show a cursor (blinking?) when they have the input
  108. focus.
  109.  
  110. Pressing the Return key sends the form's content to the server designated
  111. by the URL in the FORM tag. The server evaluates the form's contents
  112. and in this case replies by sending a document containing the form, but
  113. marked up to indicate the user has made some inconsistent choices for
  114. disk drives.
  115.  
  116. This assumes that the browser encodes the form's contents as a
  117. list of field ids and values following a "?" suffix after the URL.
  118. It may be better to define a HTTP method for form data with a clean
  119. encoding.
  120.  
  121. A suggested URL encoding:
  122.  
  123.     ? FIELD [ + FIELD ]*        -- ie FIELDs seperated by "+" --
  124.  
  125. where FIELD is:
  126.     id:value                    -- single valued fields --
  127.     id:(value[+value]*)         -- multi valued fields --
  128.  
  129. Selections would use the item id in place of the actual
  130. string value.
  131.  
  132. Special characters should be replaced by "%" followed by the
  133. two hex digits encoding the ASCII value.
  134.  
  135. The special chars are (based on Tim's URL spec for xalphas:
  136.  
  137.         + - % ( ) ! ^ & * $         (and all white space chars)
  138.  
  139. Note that URLs would then be of arbitrary length!
  140.  
  141. Best wishes,
  142.  
  143. Dave Raggett
  144.  
  145. ------------------------------------------------------------------------
  146.  
  147. <!-- Forms: these are composed from input fields and selection menus
  148.  
  149.     These elements define fields which users can type into or select
  150.     with mouse clicks. The browser should manage the input focus
  151.     e.g. with the tab/shift tab keys and mouse clicks.
  152.  
  153.     The enter/return key is then taken to mean the use has filled
  154.     in the form and wants the apppropriate action taken:
  155.  
  156.         -   send as query/update to WWW server
  157.         -   email/fax to designated person
  158.  
  159.     The action is specified as a URL, e.g. "mailto:dsr@hplb.hpl.hp.com
  160.  
  161.     You can specify additional mail headers with the MH tag:
  162.  
  163.     <MH>Subject: Please add me to tennis tournament</MH>
  164.  -->
  165.  
  166. <!ELEMENT FORM - - (MH*, (%main;|INPUT|SELECT)*)>
  167. <!ATTLIST FORM
  168.     id      ID        #IMPLIED
  169.     action  %URL;     #IMPLIED>
  170.  
  171. <!ELEMENT MH - - CDATA -- RFC 822 header fields -->
  172.  
  173. <!ELEMENT INPUT - - (%text;)>
  174. <!ATTLIST INPUT
  175.     id      ID      #IMPLIED
  176.     type    CDATA   #IMPLIED    -- URL, INT, FLOAT, DATE, BOOL, TEXT --
  177.     width   CDATA   #IMPLIED    -- precision e.g."32x4" for multiline text --
  178.     value   CDATA   #IMPLIED    -- the current value (yes/no for boolean fields) --
  179.     disabled (disabled) #IMPLIED    -- if grayed out --
  180.     error   (error)    #IMPLIED    -- if in error -->
  181.  
  182. <!-- Menu selections one from many and many from many
  183.  
  184.   The compact attribute is a suggestion that the browser renders
  185.   the list in compact style, e.g. as a dropdown menu.
  186.  
  187.   The multi attribute means the menu permits multiple selections -->
  188.  
  189. <!ELEMENT SELECT - - ((%text;)*, ITEM*)>
  190. <!ATTLIST SELECT
  191.     id      ID        #IMPLIED
  192.     compact (compact) #IMPLIED
  193.     multi   (multi)   #IMPLIED>
  194.  
  195. <!-- menu items with attributes for menu selections -->
  196. <!ELEMENT ITEM - O (%text;)>
  197. <!ATTLIST ITEM
  198.     id          ID         #IMPLIED
  199.     selected    (selected) #IMPLIED -- if selected in list --
  200.     disabled    (disabled) #IMPLIED -- if grayed out --
  201.     error       (error)    #IMPLIED -- if in error -->